Method and apparatus for establishing a secure connection

ABSTRACT

One embodiment of the present invention provides a system that establishes a secure connection with a peer. During operation, the system obtains an identity for the peer. Next, the system looks up the identity for the peer in a local store, which contains identities for trusted peers. If this lookup fails, the system asks a user if the peer can be trusted. If the user indicates that the peer can be trusted, the system establishes a secure connection with the peer.

BACKGROUND

1. Field of the Invention

The present invention generally relates to computer security. Morespecifically, the present invention relates to a method and an apparatusthat facilitates establishing a secure connection on a communicationchannel.

2. Related Art

The TLS protocol is widely used to provide security on communicationchannels. The term “security” in this context refers to the fact thatthe TLS protocol provides both privacy and authentication. Privacy isprovided by encryption of the communication channel, so thateavesdroppers cannot decipher the data that is flowing through thecommunication channel. Authentication is provided through public keycryptography, which allows a participant in a secured communication tobe reasonably sure that they are in fact talking to who they think theyare talking to. For example, public key cryptography can be used toensure that if you think you're giving your credit card number toamazon.com, you in fact are securely communicating with amazon.com andnot with an impostor.

Although the TLS protocol, is widely used (for example, every webbrowser has an implementation of client-side TLS, or at least of TLS'spredecessor, SSL), TLS is rather cumbersome to administer for servers. Asignificant administrative difficulty arises from certificatemanagement. Normally, TLS servers have a certificate which is signed bya Certificate Authority (CA) such as Verisign™. TLS clients, such as webbrowsers, contain a built-in list of CAs which they trust. Hence, if aTLS server wants to be recognized as trustworthy by such a client, theserver must first obtain a digital certificate (such as an X.509certificate) from one of the widely-known CAs. This process of obtaininga digital certificate from a widely-known CA is not a trivial matter; ittakes time, paperwork, and money.

Hence, what is needed is a method and an apparatus for establishing asecure connection without the above-described difficulties involved inmanaging digital certificates.

SUMMARY

One embodiment of the present invention provides a system thatestablishes a secure connection with a peer. During operation, thesystem obtains an identity for the peer. Next, the system looks up theidentity for the peer in a local store, which contains identities fortrusted peers. If this lookup fails, the system asks a user if the peercan be trusted. If the user indicates that the peer can be trusted, thesystem establishes a secure connection with the peer. (Note that theterm “peer” as used in this specification and in the appended claimsrefers to any type of computational device or system that can interactwith other computational devices or systems. For example, a peer can bea client or a server in a client-server system, or can be a peer in apeer-to-peer system.)

In a variation on this embodiment, the identity for the peer can berepresented by a digital certificate for the peer.

In a further variation, establishing the secure connection with the peerinvolves: starting with an unauthenticated connection with the peer;importing the digital certificate for the peer into the local store; andthen establishing the secure connection with the peer using theunauthenticated connection and the digital certificate for the peer.

In a further variation, if the digital certificate for the peer is aself-signed digital certificate, the method further comprises performingan out-of-band exchange with the peer to confirm the validity of theself-signed digital certificate.

In a variation on this embodiment, obtaining the identity for the peerinvolves performing a service discovery operation to obtain the identityfor the peer and also to obtain an unauthenticated connection with thepeer.

In a variation on this embodiment, the secure connection is a SecureSockets Layer (SSL) connection or a Transport Layer Security (TLS)connection.

In a variation on this embodiment, the local store is a Mac OS™keychain.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 illustrates a distributed system in accordance with an embodimentof the present invention.

FIG. 2 presents a flow chart illustrating the certificate creation anddistribution process in accordance with an embodiment of the presentinvention.

FIG. 3 presents a flow chart illustrating the process of identifying apeer and establishing a secure connection with the peer in accordancewith an embodiment of the present invention.

FIG. 4 presents a flow chart illustrating how a secure connection isestablished in accordance with an embodiment of the present invention.

FIG. 5 illustrates an exemplary user interface to facilitatecollaboration in accordance with an embodiment of the present invention.

FIG. 6 illustrates a representation of a digital certificate inaccordance with an embodiment of the present invention.

DETAILED DESCRIPTION

The following description is presented to enable any person skilled inthe art to make and use the invention, and is provided in the context ofa particular application and its requirements. Various modifications tothe disclosed embodiments will be readily apparent to those skilled inthe art, and the general principles defined herein may be applied toother embodiments and applications without departing from the spirit andscope of the present invention. Thus, the present invention is notlimited to the embodiments shown, but is to be accorded the widest scopeconsistent with the principles and features disclosed herein.

The data structures and code described in this detailed description aretypically stored on a computer-readable storage medium, which may be anydevice or medium that can store code and/or data for use by a computersystem. This includes, but is not limited to, magnetic and opticalstorage devices, such as disk drives, magnetic tape, CDs (compact discs)and DVDs (digital versatile discs or digital video discs), and computerinstruction signals embodied in a transmission medium (with or without acarrier wave upon which the signals are modulated). For example, thetransmission medium may include a communications network, such as a LAN,a WAN, or the Internet.

Distributed System

FIG. 1 illustrates a distributed system 100 in accordance with anembodiment of the present invention. Distributed computer system 100includes a development system 102 and a number of peer systems 110-113,which are coupled together by a network 108. Network 108 can generallyinclude any type of wired or wireless communication channel capable ofcoupling together computing nodes. This includes, but is not limited to,a local area network, a wide area network, or a combination of networks.In one embodiment of the present invention, network 108 includes theInternet.

Development system 102 supports a number of software development tools.During the software development process, development system 102 makesuse of peer systems 110-113 to perform computational operations relatedto code development. For example, development system 102 can offloadcompilation operations to peer systems 110-113. Note that the presentinvention is not meant to be limited to software development systems. Ingeneral, the present invention can be applied to any computationaldevices or systems that collaborate with each other.

To facilitate secure communications with peer systems 110-113,development system includes keychains 104 and 106. Keychain 104 includesdigital certificates which belong to development system 102, whereaspeer keychain 106 includes digital certificates belonging to peers thatdevelopment system 102 can trust. In one embodiment of the presentinvention, keychains 104 and 106 are keychains as defined within the MacOS X™ operating system.

Certificate Creation and Distribution

FIG. 2 presents a flow chart illustrating the process of creating anddistributing digital certificates in accordance with an embodiment ofthe present invention. During this process, each peer creates its owndigital certificate (step 202). This certificate creation operation canbe accomplished by calling a function, which is described in more detailbelow. Next, peers distribute their certificates to other peers thatthey want to interact with (step 204). When a peer receives acertificate for a peer that it trusts, the receiving peer installs thecertificate in its local peer keychain (step 206).

Establishing a Secure Connection

FIG. 3 presents a flow chart illustrating the process of identifying apeer and establishing a secure connection with the peer in accordancewith an embodiment of the present invention. The process starts whendevelopment system 102 performs a service discovery operation toidentify a peer system 110 that is able to perform a service, such asperforming compilation operations for development system 102 (step 302).

During this discovery process, development system 102 obtains anunauthenticated connection to peer system 110 (step 304). At this point,both peer system 110 and development system 102 call a function toconfigure a secure connection between development system 102 and peersystem 110. This function uses digital certificates from associatedkeychains and is described in more detail below.

The process of setting up a secure connection generally involves thefollowing steps which are illustrated in the flow chart that appears inFIG. 4. First, a computer system, such as development system 102,obtains an identity for a peer and an unauthenticated connection to thepeer (step 402).

Next, the system looks up the identity of the peer in a local keychain,which contains identities for peers (represented by digitalcertificates) that the system has decided to trust (step 404). If thislookup is successful, the system establishes the secure connection tothe peer using a corresponding certificate for the peer from the localkeychain (step 414).

On the other hand, if the lookup in step 404 is not successful, thesystem asks a user if the peer can be trusted (step 408). If the useranswers “no,” the system takes a remedial action (step 412). Otherwise,if the user answers “yes,” the system establishes the secure connectionto the peer (step 414). This may involve first obtaining and importing acertificate for the peer into a local keychain.

The above-described processes are described in more detail below.

Secure Collaboration

It is often desirable to enable secure, ad-hoc collaboration amongstmultiple people. A number of service discovery mechanisms exist, suchBonjour™, which can be used to establish connections for these ad-hoccollaborations. However, the techniques described below can also beapplied to connections established through other means.

Secure sessions can be established through the use of a mutual sharedsecret, such as a password. However, users are not particularly good atchoosing passwords. While this may not matter so much in a one-timead-hoc situation, it means that this process must be repeated each timethese users meet. In addition, the key distribution problem is alreadydifficult in a small meeting where, say, a third of the attendees willparticipate. Finally, this requires user interaction, which we can avoidin most cases.

Digital certificates offer a compelling solution to this problem.Through the use of digital certificates, it is possible to make thiscollaboration secure, and completely transparent in most cases. Thereason that digital certificates are not more widely used is becausemany users must have them to make effective use of them. This willchange rapidly as certificates are issued to more users.

Exemplary Embodiment

One embodiment of the present invention performs a number of differentoperations: service discovery, identity selection, trust decisions, anddata transfer. For service discovery operations, Bonjour™ can be usedbecause it is convenient, and also because it is ideal for ad hoccollaboration. Data transfer operations can be accomplished using anyconvenient technique. In one embodiment of the present invention, datatransfer operations are performed through sockets as is discussed below.Identity and trust are also discussed below.

One embodiment of the present invention provides a client/serverapplication that publishes and discovers availability through Bonjour™,and which authenticates using digital certificates.

An exemplary user interface for this application appears in FIG. 5. Inthe screenshot of the main window list in FIG. 5, the list box containsa list of “servers” that will send a picture to the client if clickedon. The certificate shown next to “jurljo4” indicates that the systemhas received a certificate from that “server.” The information above thelist box is the information for this “server.” In FIG. 5, the itemscontained in the “Debug” box can be considered as advanced features orinformational only. These items provide more detail about the serverwhich is highlighted in the main window list. Note that the items in thelist box are exemplary items and can in practice have differentinformation than is shown in FIG. 5.

The simplified view of a certificate illustrated in FIG. 6 shows most ofthe essential information in a very compact form, and makes it easy forthe user to do their own quick assessment of whether to trust it or not.Note that although this certificate may validate successfully, it mightnot be the particular “Ken Jones” that the user wants to communicatewith.

Identity Search

In one embodiment of the present invention an identity is defined to bea public/private key pair that satisfies certain properties. In general,the present invention can use any identity that supports clientauthentication. A trust policy can be defined to focus the search and toverify that the identity is valid for this purpose. In the case wherethe user does not have any identity, the system can generate aself-signed certificate.

In one embodiment of the present invention, all of the user keychainsare searched for identities that could be used for collaboration. Thelocated identities are then displayed in the popup menu shown below. Theability to select a specific identity to use for collaboration canpossibly be available in a preferences pane somewhere, but in general wecan just pick the “best” identity for the user and use that forcollaboration. Note that this approach allows the system to use anyidentity which satisfies the “collaboration” trust policy. This caninclude:

-   -   Certificates issued by a company for its customers;    -   Certificates issued by a Certificate Authority;    -   Certificates on a smart card; and    -   Self-signed certificates.        In many or most cases, the system can select one of these        automatically to avoid user interaction. The only case that        demands some user interaction is the self-signed certificate.        Certificate Transport

The first time a collaboration is initiated, the public certificates ofthe participants need to be exchanged. This can be done as part of theSSL/TLS exchange. Technically, this can involve a call toSSLGetPeerCertificates after the call to SSLHandshake. Thesecertificates can then be added to the user's keychain for use in futurecollaboration sessions.

Trust Issues

For certificates signed by a trusted certificate authority (i.e. onewhose root is in the system root certificate database), trust can beestablished quickly by seeing if the name is as expected (e.g. I'mtalking with Sam so sam@mac.com is good). For self-signed certificates,a one-time out-of-band exchange needs to happen. This can involve usingpair of words selected from a dictionary based on some component of theSHA-1 hash can be shown to the user and confirmed verbally.

After the user has accepted the certificate (mechanism unspecified), itcan be shown the next time without the warning badge.

Certificate Properties

A certificate associated with an identity which is used in this schemecan have certain properties. One of the most important properties is keyusage. Some possible values for id-ce-keyusage are: digitalsignature,nonRepudiation, keyEncipherment, keyAgreement, keyCertSign, cRLSign,encipherOnly, and decipherOnly.

The extended key usage fields may also be interesting: id-kp-serverAuthand id-kp-clientAuth.

Other fields may be set, but at least one of digitalsignature,keyEncipherment, keyAgreement should be present.

For a definition of these fields, see RFC 2459, Internet X.509 PublicKey Infrastructure Certificate and CRL Profile, IETF, January 1999, athttp://www.ietf.org/rfc/rfc2459.txt.

Configuring and Using the System

To use the system, a user must be associated with an identity of sometype in one of the user's keychains. If the user does not have such anidentity, the user can obtain one by making a call to one of thefunctions described below.

SecBonjour Library

The above-described system operates by making calls to a special libraryof functions, called the “SecBonjour” library, which provides securityon a communication channel. The SecBonjour library does not require anyheavyweight (e.g. enterprise-wide or larger) administration, but isinstead administered by users of individual machines. The degree ofsecurity of a given communication channel can vary, and is solelydetermined by configuration performed by the users of the machine(s)which are involved in the communication.

The SecBonjour library relies on Transport Layer Security (TLS) tosecure a communication channel. TLS provides a secure channel between aserver (e.g. a web server) and a client (e.g., a web browser). Animportant aspect of SecBonjour, which enables administration andconfiguration in a Bonjour-style manner is that the entire subject ofCertificate Authorities can be bypassed, making the user of each machinea CA if they so desire.

The SecBonjour library provides one simple function which, when called,installs a TLS server certificate in the user's keychain, and alsoprovides a copy of the certificate which the user then distributesthrough normal, insecure channels (email, etc.) to other SecBonjourusers. Other users then, at their own discretion, import thiscertificate into their own keychains (either with the Keychain Accessapp, or via a simple C function). For example, Alice creates hercertificate and gives a copy of the certificate to Bob, who then importsAlice's certificate into his own keychain. Bob can then initiate securecommunication with Alice, with certainty that it is Alice at the otherend of the pipe/socket/whatever. The authentication can go both ways, sothat Bob can create his certificate and give it to Alice, who importsthat certificate into her keychain. In this case, a communicationchannel can be created in which both Alice and Bob are certain of theidentity of the entity at the other end of the channel.

The degree of authentication for a given channel is flexible and isdetermined by configuration options performed at both ends of thechannel, as well as by the distribution of certificates. Users in a verytrusting environment who do not wish to perform any authentication don'thave to create or distribute certificates; they can createunauthenticated (but encrypted) communication channels. (Please notethat such a communication channel, while encrypted, actually providesvery little of what is widely considered to be “Security,” since neitherentity has any idea of who they are talking to. The entities could betalking to a hostile entity who is for example trying to coax them intogiving out their password.) Individual devices can provide certificates,without requiring certificates from clients which use the device.Individual devices and clients can require two-way authentication,rejecting connections which do not meet this criteria.

Given a current state of certificates and user preferences, establishinga secure connection between a client and a server (or in Bonjour lingo,a client and a device) involves calling a single function in theSecBonjour library. This function is called after a basic (insecure)socket-level connection has been established between the client and theserver. Subsequent communications over the secure channel are performedby simple read and write calls.

One embodiment of the SecBonjour library provides three high-levelfunctions. One of these functions, SR_CertificateAndKeyCreate( ), isused to create a private key and a certificate for a given node. (Werefer to both the server and the client as SecBonjour nodes.) Thisfunction is called by the administrator of a specific device if clientsof that device wish to authenticate the device when they establish aconnection to it. OSStatus SR_CertificateAndKeyCreate( CFStringRefhostName, CFStringRef userName, SecKeychainRef keychain, CFDataRef*cert); // RETURNEDwhere,

hostname is the name of host on which this certificate will be used. Itis the same as the name by which clients will connect to the host—e.g.,“crypto.apple.com.” This string must be convertible to an ASCII Cstring. In the spirit of Bonjour-style local configuration, this can besomething as generic as “localhost” (if all of the nodes which will beusing this certificate reside on the same host), or a link-local namelike “tower.local.”

username is strictly for human readability. It can denote the same ofthe device associated with the certificate (“Doug's Laser Printer”), auser (“Derek”), or anything else. This string must be convertible to anASCII C string.

keychain is a reference to an open keychain, to which the createdcertificate and private key will be written.

cert is a copy of the created certificate. This certificate, which isabout 500 bytes of binary data, is typically distributed to otherSecBonjour users, who import the certificate into their own keychainsvia SR_CertificateImport( ). This certificate is not sensitive; it canbe carried about freely, sent via email, etc. The actual implications ofanother user actually importing this certificate into their own keychainare discussed in the section entitled “Security Considerations”.

The SR_CertificateImport( ) function is used to import certificatescreated by other users. These certificates are created bySR_CertificateAndKeyCreate( ). Generally, when a user performs thisoperation, they are indicating that they wish to implicitly trust theowner of the certificate being imported. OSStatus SR_CertificateImport(SecKeychainRef keychain, CFDataRef cert);where,

keychain is a reference to an open keychain, to which the importedcertificate will be written.

cert is the certificate created by SR_CertificateAndKeyCreate( ).

The SR_SecureTransportConfigure( ) function is used to establish asecure TLS channel. It is called after basic a socket-level connectionhas been established. The same function is used on the server side andthe client side of a connection. On return from this function, a securecommunication channel exists, and secure communication can be performedwith the peer using the SSLRead( ) and SSLWrite( ) functions (declaredin <Security/SecureTransport.h>).

When the application is finished using the channel, it can callSSLClose( ) to flush any remaining buffered I/O, and then callSSLDisposeContext( ) to free up the SSLContextRef. OSStatusSR_SecureTransportConfigure( int sock, CFStringRef peerHostName, boolisServer, bool requirePeerAuthentication, SecKeychainRef myCertKeychain,SecKeychainRef peerCertKeychain, SSLContextRef *sslContext); // RETURNEDwhere

sock is a UNIX socket representing a connection to a peer. If this is aserver, accept( ) has already been called. If this is a client, connect() has already been called.

peerHostName is the name of the peer host, e.g., “crypto.apple.com”.Specifying this is optional; if you don't know the peer's host name,pass in NULL. (Doing so is actually quite common on the server side,where it is cumbersome or impossible to know the host name of theclient.) Specifying a non-NULL host name provides additionalauthentication by requiring that the peer's certificate is indeed fromthe specified host name. If specified, this must match exactly the namein the peer's certificate, as provided in the hostname argument whenSR_CertificateAndKeyCreate( ) was called. isServer determines if this isa client or a server node.

requirePeerAuthentication: Setting this to true means that the peer mustpresent a certificate which we recognize by its presence inpeerCertKeychain.

myCertKeychain optionally specifies the location of this node'scertificate. If not specified, the peer must be willing to accept anunauthenticated connection. Caller must hold a reference to the keychainthroughout the TLS session.

peerCertKeychain: Optionally specifies a keychain containingcertificates of trusted peers; required if requirePeerAuthenticationtrue, else optional. Caller must hold a reference to the keychainthroughout the TLS session.

Authentication Options

Administrators of individual SecBonjour nodes have a good deal offlexibility in specifying the degree of authentication which can be, ormust be, performed when their node is involved in SecBonjourcommunication. For the purposes of this library, this degree ofauthentication is determined by the arguments toSR_SecureTransportConfigure( ) and by the contents of the keychainsprovided to that function, if any. Authentication is performed via TLS,so a brief discussion of the options available in TLS is in order. TLSprovides three styles of authentication.

no authentication—No certificates are involved, and no assurance as tothe identity of the peer is provided.

server-side authentication (only)—In this style, a client can be assuredof the identity of a server, and the server is willing to provide itsservice promiscuously. Most TLS-enabled web servers operate in thismanner. The server has a certificate which is verifiable by the client.The main purpose of this style of authentication is to assure a clientthat sensitive information she is providing over the channel (password,credit card number) is only being seen by the server which is the actualintended recipient of the data. Note that this sensitive informationcan, and often is, used by the server to identify and authenticate theclient using means outside the scope of TLS.

server-side and client-side authentication—Both sides have a certificatewhich is verifiable by the other side.

Note that TLS does not allow client-side authentication withoutserver-side authentication.

Per the Bonjour paradigm, authentication can be administered locally, bythe owners of the machines or services involved. The actual form ofauthentication to be used in a given TLS session is negotiated duringthe establishment of a session; the familiar “best thing that bothparties agree they can do” is negotiated. Both nodes can effectivelyspecify minimum and maximum levels of authentication they are willingand able to do, and each node can, by the presence of other nodes'certificates in the keychain passed to SR_SecureTransportConfigure( ),restrict connections to only nodes authorized by the administrator(i.e., the owner of the keychain).

Here is a description of the arguments to SR_SecureTransportConfigure( )which determine what style of authentication is performed between twospecified nodes, with descriptions of the relation of these variables tothe actual negotiated authentication.

myCertKeychain contains this node's certificate and private key. Ifeither of those are absent, or myCertKeychain is NULL, this node can notbe authenticated by the peer.

peerCertKeychain contains the certificates of peers one is willing toaccept authenticated connections to. If this keychain is empty, orpeerCertKeychain is NULL, peers can not be authenticated.

requirePeerAuthentication indicates whether this node requires peers tobe authenticated. Specifying a value of true for this, while specifyingaNULL or empty peerCertKeychain, is illegal. Specifying a true value forthis, while the peer node has not provided a peerCertKeychain, willresult in negotiation failure.

Note that myCertKeychain and peerCertKeychain can be identical.

Also, note that the only way for a full server- and client-sideauthentication to be successfully performed is for both server andclient to provide valid myCertKeychain arguments when they each callSecureTransportConfigure( ), and for both nodes to have copies of theother node's certificate in the peerCertChain argument toSecureTransportConfigure( ).

If the criteria specified in the previous bullet item are not met, andeither node specifies a value of true for requirePeerAuthentication, thenegotiation will fail.

There is a non-obvious failure mode which must be recognized andpotentially handled by clients. Suppose node1, a server, has both kindsof kevchain—private key and certificate in node1CertKeychain, and a setof peer certificates in node1PeerCertKeychain. Also, suppose node2 issimilarly configured, with node2CertKeychain and node2PeerCertKeychain.

But suppose that node1's own certificate is not contained innode2'snode2PeerCertKeychain. Now a SecBonjour is attempted betweenthese two nodes, with node2 as the client, with both nodes specifyingfalse for requirePeerAuthentication. This connection attempt will fail,because node2 is configured to attempt to authenticate node1 (due to thepresence of valid certificates in node2PeerCertKeychain), but there isno certificate for node in node2's peerCertKeychain. Hence, Node2's callto SR_SecureTransportConfigure will return errSSLUnknownRootCert.

The application must detect this and perhaps retry the connection,specifying a NULL value for peerCertKeychain (indicating that it is notinterested in even attempting to perform peer authentication). If andonly if node1 is configured with requirePeerAuthentication false, thissubsequent connection attempt will succeed.

Example Programs

Two example programs are provided with SecBonjour. One, srCertTool,illustrates the administration of certificates. The other, srT1sNode,illustrates the establishment and use of a secure connection.

srCertTool

This program is a command line tool which illustrates the use of the twoSocBonjour certificate-related functions:

SR_CertificateAndKeyCreate and SR_CertificateAndImport. It has twooptions: one to create a certificate, and one to import an existingcertificate.

Creating a certificate and a private key is performed like this: %srCertTool create <hostname> <username> <keychain> <certfile>This results in a private key and certificate being created with thespecified hostname and username, and the certificate is added to thespecified keychain. The resulting certificate, which is typically givenout to other SecBonjour users, is written to the file specified bycertfile. The specified keychain must already exist.

To import an existing certificate into a keychain, do this:

-   -   % srCertTool import <keychain> <certfile>

Suppose two nodes wish to be able to establish a fully authenticatedchannel (in which both the server and the client are authenticated).Both nodes must create a cert and give that cert to the other node,which imports that cert into their keychain. Say the first node is athostname “host1.local.”, its own certificate is to be kept innode1Cert.kc, and its peer certificates are to be kept innode1PeerCert.kc. Similarly, the second node has values of“host2.local”,node2Cert.kc, and node2PeerCert.kc.

First node1 does this: % srCertTool create host1.local. node1node1Cert.kc node1Cert.cer

While node2 does this: % srCertTool create host2.local. node2node2Cert.kc node2Cert.cer

Then the two entities (or their administrators) exchange the resultingcertificate files, and these two steps are performed: % srCertToolimport node1PeerCerts.kc node2Cert.cer % srCertTool importnode2PeerCerts.kc node1Cert.cer

At this point, both nodes have the necessary certificates and keychainsneeded to authenticate each other using SecBonjour.

srTlsNode

This program is a command line tool behaves as either a server or aclient. It illustrates the use of the SR_SecureTransportConfigure( )function. Its usage is as follows:

srTlsNode s[erver]|c[lient] [options]

Options: −h hostname (default=localhost) −P port (default = 1200) −mmyCertKeychain −p peerCertKeychain −r[equirePeerAuthentication] −n(don't use hostname for authentication)

These options map directly to the arguments to theSecureTransportConfigure( ) function. The ‘-n’ option is typically usedin the server case, when the host name of the client is not known whensrTlsNode is run (note that this is actually a common situation forservers in the real world.) When this option is specified, a NULL ispassed as peerHostName in the call to SR_SecureTransportConfigure( ).

To illustrate the use of this program, assume that node1 and node2 haveset up their keychains as described in the previous example, and thatnode1 is to be a server, and node2 is to be a client.

First run srTlsNode as a server for node 1, and see the followingoutput: % srTlsNode server −h host2.local. −m node1Cert.kc − pnode1PeerCerts.kc ...listening for client connection on port 1200

Then run srTlsNode as a client for node 2, and see the following output:% srTlsNode client −h host1.local. −m node2Cert.kc −p node2PeerCerts.kc...connecting to host host1.local. at port 1200 ...establishing secureTLS connection ...Authenticated (RSA) connection established ...clientauthentication successfully performed Type some text to send to server,terminated by CR. A line starting with ‘Q’ terminates the session.

After which the srTlsNode running at node1 will display the following:...establishing secure TLS connection ...Authenticated (RSA) connectionestablished ...client authentication successfully performed ...waitingfor data from client

At this point, text that you enter at the node2 client will be securelysent to node1 and displayed there; then you can type in text at node1 tosend it to and be displayed at node2. Either node ends the session byentering ‘Q’. There is a csh script which performs a simplified versionof the four separate runs of srCertTool described above. This script, inscripts/makeLocalCerts, creates the four keychains described in theabove examples, with the exception that hostname is “localhost” for allof the certificates. This allows the certificates to easily be used whenthe server and client are on the same machine.

The Trustworthiness of a Certificate

From a security perspective, one difference between a SecBonjourconnection and a conventional TLS connection is in the evaluation andverification of the peer's certificate(s). Normally, a TLS server has acertificate signed by a known Certificate Authority (CA), and there is alist of known, trusted CAs maintained either by an application or by thesystem on the client side. SecBonjour, on the other hand, relies on thepresence of root certificates in an arbitrary keychain, manipulated bythe user at will. The problem with this is that the addition of acertificate into a user's keychain can be performed by any programrunning as that user—with no user interaction or notification. Akeychain does not have to be unlocked for a rogue application to add acertificate to it—the rogue app just has to have the same UID as theowner of the keychain.

One solution to this problem of relatively insecure keychains is tostore the SecBonjour certificate in the system keychain. In thisscenario, someone would have to type in the admin password to add acertificate. Another, future possibility involves the specification ofAccess Control Lists (ACLs) along with root certificates, so that forexample, only certain applications can access them. In anotherembodiment of the present invention, the system assigns per-user,per-certificate “trust” to individual certificates.

User Evaluation of A Certificate's Trustworthiness

Since SecBonjour does not rely on a set of system-wide trustedcertificates, the trust resides in a user's keychain, and the assignmentof trust is solely at the discretion of the user. It is also the soleresponsibility of the user. Those familiar with the Pretty Good Privacysystem (PGP) may have encountered PGP's stem warning along the lines of“Are you really sure you want to trust this public key?” The same thingpertains here: if you add a certificate to one of your keychains whichwill be used by SecBonjour to authenticate peers, you are responsiblefor determining:

a) whether you want to trust the person or service to which thecertificate belongs; and

b) whether the certificate you are importing actually belongs to thatperson or service.

The first item is self-evident, and everyone knows how to make thatdecision. (Do you want to allow Bob to use your printer, or not?) Thesecond item is much harder; it is non-intuitive; it's actually thereason for the existence of the global public key infrastructure (PKI)involving hierarchies of certificates and widely-known CAs likeVeriSign. Since SecBonjour deliberately bypasses the entire establishedPKI, the result is that the user has to make the determination as towhether, for example, this certificate I'm about to import into mySecBonjour keychain really does represent Bob's printer, or the personacross the hall who wants to use my backup drive.

Before importing such a certificate into one's SecBonjour keychain, theuser should ideally carefully investigate the origin of the certificate.Some examples of situations which represent dubious certainty that acertificate is what it claims to be are:

(1) The certificate was downloaded from a web site associated with theservice or user it represents.

(2) The certificate came off a CD sitting around in the room where aprinter resides.

(3) The certificate came in an email which purports to be “From” theowner of the certificate (and of the service it represents), with nofurther corroboration.

Some examples of situation which give a good degree of certainty that agiven certificate belongs to the service or user which it claims torepresent are:

(1) The user personally hands you a CD or USB dongle containing hiscertificate.

(2) The certificate comes in an email which also contains answers toquestions which you have asked, and which only the person associatedwith the certificate can be expected to know the answers to.

(3) The certificate comes from a server which provides a trustedcommunication channel, secured outside of the SecBonjour mechanism.

(4) The “Fingerprint” of the certificate has been published in sometrustworthy manner (say, in a hard copy document the user widelydistributed, or on a web site which is so widely used that it would beobvious it were being spoofed), and you verify that fingerprint usingKeychain Access.

The foregoing descriptions of embodiments of the present invention havebeen presented only for purposes of illustration and description. Theyare not intended to be exhaustive or to limit the present invention tothe forms disclosed. Accordingly, many modifications and variations willbe apparent to practitioners skilled in the art. Additionally, the abovedisclosure is not intended to limit the present invention. The scope ofthe present invention is defined by the appended claims.

1. A method for establishing a secure connection with a peer,comprising: obtaining an identity for the peer; looking up the identityfor the peer in a local store, which contains identities for trustedpeers; and if the lookup fails, asking a user if the peer can betrusted, and if the user indicates that the peer can be trusted,establishing the secure connection with the peer.
 2. The method of claim1, wherein the identity for the peer can be represented by a digitalcertificate for the peer.
 3. The method of claim 2, wherein establishingthe secure connection with the peer involves: starting with anunauthenticated connection with the peer; importing the digitalcertificate for the peer into the local store; and establishing thesecure connection with the peer using the unauthenticated connection andthe digital certificate for the peer.
 4. The method of claim 3, whereinif the digital certificate for the peer is a self-signed digitalcertificate, the method further comprises performing an out-of-bandexchange with the peer to confirm the validity of the self-signeddigital certificate.
 5. The method of claim 1, wherein obtaining theidentity for the peer involves performing a service discovery operationto obtain the identity for the peer and also to obtain anunauthenticated connection with the peer.
 6. The method of claim 1,wherein the secure connection is a Secure Sockets Layer (SSL) connectionor a Transport Layer Security (TLS) connection.
 7. The method of claim1, wherein the local store is a Mac OS™ keychain.
 8. A computer-readablestorage medium storing instructions that when executed by a computercause the computer to perform a method for establishing a secureconnection with a peer, the method comprising: obtaining an identity forthe peer; looking up the identity for the peer in a local store, whichcontains identities for trusted peers; and if the lookup fails, asking auser if the peer can be trusted, and if the user indicates that the peercan be trusted, establishing the secure connection with the peer.
 9. Thecomputer-readable storage medium of claim 8, wherein the identity forthe peer can be represented by a digital certificate for the peer. 10.The computer-readable storage medium of claim 9, wherein establishingthe secure connection with the peer involves: starting with anunauthenticated connection with the peer; importing the digitalcertificate for the peer into the local store; and establishing thesecure connection with the peer using the unauthenticated connection andthe digital certificate for the peer.
 11. The computer-readable storagemedium of claim 10, wherein if the digital certificate for the peer is aself-signed digital certificate, the method further comprises performingan out-of-band exchange with the peer to confirm the validity of theself-signed digital certificate.
 12. The computer-readable storagemedium of claim 8, wherein obtaining the identity for the peer involvesperforming a service discovery operation to obtain the identity for thepeer and also to obtain an unauthenticated connection with the peer. 13.The computer-readable storage medium of claim 8, wherein the secureconnection is a Secure Sockets Layer (SSL) connection or a TransportLayer Security (TLS) connection.
 14. The computer-readable storagemedium of claim 8, wherein the local store is a Mac OS™ keychain.
 15. Anapparatus for establishing a secure connection with a peer, comprising:an identity-obtaining mechanism configured to obtain an identity for thepeer; a lookup mechanism configured to look up the identity for the peerin a local store, which contains identities for trusted peers; and aconnection-establishing mechanism, wherein if the lookup fails, theconnection-establishing mechanism is configured to ask a user if thepeer can be trusted; wherein if the user indicates that the peer can betrusted, the connection-establishing mechanism is configured toestablish the secure connection with the peer.
 16. The apparatus ofclaim 15, wherein the identity for the peer can be represented by adigital certificate for the peer.
 17. The apparatus of claim 16, whereinthe connection-establishing mechanism is configured to: start with anunauthenticated connection with the peer; import the digital certificatefor the peer into the local store; and to establish the secureconnection with the peer using the unauthenticated connection and thedigital certificate for the peer.
 18. The apparatus of claim 17, whereinif the digital certificate for the peer is a self-signed digitalcertificate, the connection-establishing mechanism is configured toperform an out-of-band exchange with the peer to confirm the validity ofthe self-signed digital certificate.
 19. The apparatus of claim 15,wherein the identity-obtaining mechanism is configured to perform aservice discovery operation to obtain the identity for the peer and alsoto obtain an unauthenticated connection with the peer.
 20. The apparatusof claim 15, wherein the secure connection is a Secure Sockets Layer(SSL) connection or a Transport Layer Security (TLS) connection.
 21. Theapparatus of claim 15, wherein the local store is a Mac OS™ keychain.22. A function library embedded on a computer-readable storage medium,wherein the function library includes a first function for establishinga secure connection with a peer, wherein the first function isconfigured to: obtain an identity for the peer; look up the identity forthe peer in a local store, which contains identities for trusted peers;and if the lookup fails, to ask a user if the peer can be trusted, andif the user indicates that the peer can be trusted, to establish thesecure connection with the peer.
 23. The function library of claim 22,wherein the function library includes a second function for creating aprivate/public key pair and a corresponding a digital certificate for agiven node.
 23. The function library of claim 22, wherein the functionlibrary includes a third function for importing a digital certificatefor a peer into a local store.
 25. The function library of claim 22,wherein the identity for the peer can be represented by a digitalcertificate for the peer.
 26. The function library of claim 25, whereinwhile establishing the secure connection with the peer, the firstfunction is configured to: start with an unauthenticated connection withthe peer; import the digital certificate for the peer into the localstore; and to establish the secure connection with the peer using theunauthenticated connection and the digital certificate for the peer. 27.The function library of claim 26, wherein if the digital certificate forthe peer is a self-signed digital certificate, the first function isconfigured to perform an out-of-band exchange with the peer to confirmthe validity of the self-signed digital certificate.
 28. The functionlibrary of claim 22, wherein while obtaining the identity for the peer,the first function is configured to perform a service discoveryoperation to obtain the identity for the peer and also to obtain anunauthenticated connection with the peer.